
Ron'sWeek'n'ADAM

September 16, 1997


Why are there not more people writing programs for ADAM in Z80
assembly language? Why are there not more people writing prog-
rams for ADAM in C or SmartBasic 1.x?  For that matter, why are
there not more people writing programs for ADAM in Forth, 
Pascal, Fortran, or whatever their heart pleases? Why don't you
write programs for the ADAM?  Have you ever wondered about this
deep and painful question? Sometimes people I know put up emot-
ional fences when the subject of programming comes up. They 
don't even want to talk about it. I've never understood that. 
Under those circumstances I often get the impression people feel
that the  conversation has shifted from whatever was legitimate 
to that which is not, to something that is almost a mystical and
cauldron bubbling art. 
It's not  really rocket science you know.  But it can sometimes 
seem that way; case in point follows: 

Late one night at ADAMCON 09, Gene Welch (dpwgene@msn.com) and I
were trying to figure out the Dynomite Sound Digitizer (Trisyd 
Video Games, Toronto - Syd Carter, developer). I wanted to in-
clude the Digitizer in my  MIDI presentation the following morn-
ing and I was really scrambling.  It was one of those products 
that I just had to have at ADAMCON 02, and having  acquired it 
I left it to gather dust sitting in the least used ADAM in my
collection. Apart from a couple of demos at ADAM User Friendly 
Group meetings  in Ottawa, little use was made of this unique 
and original device. I never took the trouble to understand it,
and neither did many other people.  That I don't understand 
either.  At any rate, through trial and error, Gene and I got 
the state of our knowledge about the Digitizer to the point 
where we had figured out a few very basic things, and on that 
basis the demo proceeded. 
To make a long story even longer, Gene sent me an E-mail fol-
lowing my return from Grand Rapids asking about a program that 
was supposed to have been included with the Dynomite distribu-
tion disk, a program called 'basplyr'. Gene wanted to use his 
Digitizer to produce sound files for use in his programs - a 
capability that Syd had provided through a pair of programs
accessible from SmartBASIC. Gene advised that he'd been unable
to find 'basplyr' and would I please send a copy. Being eager 
to oblige, I located my original Dynomite Sound  Digitizer 
distribution disk and had about as much luck as Gene in locat-
ing the file. In looking through the files one by one, I 
finally came upon one called "Copyright", which contained Z80 
source code for a machine language overlay, along with a brief
description of how it could by used with another program call-
ed Dynoplyr10 to allow play of digitized sound files under 
SmartBASIC. Z80MR was recommended by the author for assembly 
of the file. I wrote Gene with this information, and he wrote
back a couple of days later saying that he'd tried the assembly
but had been unable to open the input file.  Now this partic-
ular file contains a few paragraphs of introductory text,
asking users not to distribute the code and imposing other 
limitations on its use. Following this text, the commented Z80 
source code begins. The trick is to delete the text from this 
file so that it contains only Z80 code or comment lines beginn-
ing with a semi-colon. The place to begin is easy enough to 
spot. You then re-save the file and load Z80MR (available as
PD these days, I think) to assemble the file. This is where 
Gene got stopped. 

Lesson 1

When you load Z80MR and a source code file to be assembled, the
Z80 source file should appear on the command line *without* the
file extension. So let's suppose for the sake of arguement,
the Z80 code retrieved from the file "Copyright" was renamed as 
                basplyr.Z80
The assembler command line would then read:
                Z80MR basplyr

I've found this to be the case with most Z80 assemblers that 
I've used. As a rule, they do not like file extensions, because 
following the input file name, they usually expect to find other
parameters or switches in place of  the 3 letter file extension.

Moving right along.....

Z80MR went to work and informed me that it had assembled the 
input file with no errors. Great stuff - except that this pro-
cess has been completed under TDOS. Sure enough, the directory
where the assembly had taken place now contained new files in 
addition to the original source: 
                basplyr.prn
                basplyr.hex

Using FC.COM I transferred basplyr.hex to EOS and put it in the
same directory as the Dynoplyr10 file, renaming it as basplyrH.
The author claims that although  his basplyr overlay is assem-
bled to load at 0100H,  there is an offset included in the file
to ensure that it loads at the required address under SmartBasic
This fact sailed straight over my head. Looking at the Smart-
BASIC file Dynoplyr10, I saw that one of its first actions was 
to BLOAD the file basplyr. So I ran it. 
When ADAM regained consciousness...... 
There was the error message:

                filetype mismatch

I tried using Filemanager to rename basplyr as a binary (CNTL-B)
file instead of an H file. I even tried making it an A file. 
That shows you how much I know about SmartBASIC. 

Lesson 2

Before conversion from TDOS to EOS, the assembled object file 
- basplyr.hex - has to be *LOADED*. To accomplish this, you use
a CP/M 2.2 program called  
                LOAD.COM
which reads the file basplyr.hex and loads it starting at 0100H,
which is where all CP/M or TDOS .COM files begin. The resulting 
file,           basplyr.com
can be transferred from TDOS to EOS using the FC.COM file 
conversion utility,  where it will perform as advertised.

Dynoplyr10 works with the assembled overlay basplyr. It will 
play a sound file produced with the Dynomite Sound Digitizer 
whether or not the Digitizer cartridge is present. In other
words, you can use this program to load  short sound files 
into your SmartBASIC programs.

I shall have to write Gene Welch and tell him all this.

I suppose it might serve to explain why there aren't more 
people writing programs for ADAM. 

-Ron

